home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1199 / 924 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.9 KB
  1. From: hyc@hanauma.jpl.nasa.gov
  2. Subject: Re: Binary COnfigurations 
  3. Date: Thu, 20 Jan 94 21:44:58 PST
  4.  
  5.  
  6.   ==============================
  7.   Ofcourse some sort of standard configuration tool to modify the hardcoded
  8.   paths (and other things as well) is very welcome. It enhances the flexibi-
  9.   lity of the system. And I don't mean make+compiler+assembler+linker+...,
  10.   but one simple tool, that doesn't need a lot of resources.
  11.   ==============================
  12.   
  13.   It should be possible, with GNU anyway, to modify the executable by
  14.   using the symbol-table.  It wouldn't work once the symbol table was
  15.   stripped, but once configured on your personal system you could then
  16.   strip the symbol table if you like.
  17.   
  18.   A simple utility to just list string variables and allow them to be
  19.   edited, with perhaps a fancy GEM interface to make things easier.  By
  20.   choosing standard identifier names one could quickly find the right
  21.   variable to change.
  22.   
  23.   The problem here is that you would need one binary configuration program
  24.   for GNU C, one for Lattice, one for DRI, or whatever other symbol-table
  25.   formats there are, because I think they are all different.
  26.   
  27. No, when you're dealing with a TOS executable, the various symbol-table
  28. formats really don't come into play. The GNU linker outputs DRI format
  29. symbols, or optionally GST format, which is only a minor extension to
  30. allow 22-character symbol names. No big deal.
  31.  
  32. Hm. You could construct an array of pointers, and store the actual
  33. configuration strings somewhere else, like the end of the text or data
  34. segments. The difficulty would be in correcting the segment size info in
  35. the program header (easy) and correcting any relocation info (more tedious,
  36. but also pretty easy...) Yes, a binary config tool could be done as described
  37. here.
  38.  
  39. I'm still more inclined to an environment variable approach, since that really
  40. is what they're for, and the Unix precedent already exists. (e.g., TMPDIR,
  41. TERMCAP, etc...)
  42.  
  43. re: previous message, MiNT bug - perhaps the program you are trying to run,
  44. which always crashes again after crashing the first time, is a shared-text
  45. program that has over-written its text segment. Usually shared-text code is not
  46. cached, i.e., after the last process executing it exits, the shared region is
  47. released, but if the process is dying in some unusual manner, perhaps MiNT
  48. doesn't get to mark the region as free. Then, the next time you try to execute
  49. the program, you get the bad in-memory copy... You could verify this by first
  50. checking to see if the problem program is a sharable file, and then, after it
  51. has crashed once, touch the file (update its timestamp) and try to run it again.
  52. MiNT *should* notice that the timestamp is different, and load the "new" file
  53. instead of re-using the in-memory image. (I say should, it's been a while and
  54. I haven't checked. At one time MiNT only checked the pathname, not the time
  55. stamp of the file...)
  56.